User requirements for meeting support technology

There are many kinds of information technology that can be used to make meetings more productive, some of which have more to do with what happens before and after meetings than during them. Document repositories, presentation software, and even intelligent lighting can all play their part. In our discussion of user requirements, we will restrict ourselves to considering systems that draw on the multimodal signal processing techniques described in the earlier chapters of this book to capture and analyze meetings. Such a system might help people understand something about a past meeting that has been stored in an archive, but it might equally well aid meeting participants in some way during the meeting itself. It might help system users understand what has been said at a meeting, or it could serve some other purpose — conveying an idea of who was present, who spoke and what the interaction was like, for instance. We will refer to all such systems, regardless of their purpose or when they are used, as “meeting support technology”. In the classic approach to software development, user requirements are set early the process and do not change as development proceeds. This approach causes difficulties for meeting support technology, as it does for many other kinds of software, because multimodal signal processing raises the possibility of very new kinds of systems that many potential users have trouble imagining. We begin by describing the most well-known models for the software development process and explaining why they break when user requirements are hard to to define. We then introduce the approach that evolved to fit the needs of this community. In a nutshell, what is required is an iterative process that through interaction between developers and potential users, gradually narrows and refines sets of user requirements for individual applications. Finally, we both illustrate the approach and lay